2019/1/1 第二代產品專案正式啟動，並且選擇在全公司月會，進行動土儀式，期許可以「敏捷」地完成產品開發。

第一次以敏捷團隊之姿，啟動「Sprint1」，本職為系統分析師（SA）的我，開始將抽像的需求轉換成顆粒較小的功能項目，使用user story方式撰寫規格，並提早在sprint1開始之前，就完成撰寫需求故事。接著在衝刺會議向工程師、UX說明需求故事，再由團隊腦力激盪一起設計畫面且討論需求，衝刺會議時間約4-5小時，衝刺頻率為三週。

使用最傳統的方式，利用便條紙的方式，黏貼在牆上，作為專案看板，可以清楚顯示每項故事的進行進度，並且每日進行站立會議，更新每一項任務的進度，直到衝刺的最後一天，團隊將在展示會議demo當前衝刺完成的工作項目。

如何撰寫故事：
1. User Story是給開發者們去實現目的，要使用者採取甚麼樣的操作還有調整空間。
2. User Story 強調透過一份簡單的情境規格，具體的描述出軟體在「使用者」的手上，是怎麼樣被「操作」的。
3. 刀的真義，不在殺，在藏 user story 的真義，不在格式，在講 講出來，講清楚，講的人懂。
4. User story是採取價值驅動，價值會比規格更加重要。

驗收標準應該包含：
• 功能的負面場景
• 用戶故事對其他功能的影響
• 用戶體驗問題
• 功能和非功能用例
• 性能問題和指導方針
• 系統和功能的用處
• 功能系統不能和不應該做的事
• 端到端的用戶流